Reviewable commit-by-commit (recommended)

I wasn't overly happy with the original code, but it worked, so it was fine. Now that we're looking at adding other models/providers/classifiers it feels like a good idea to make the code a bit cleaner.

Previously, the code abstracted the idea of a provider within a single generic "OpenAI filter". This meant it was testable, but was complicated to set up and follow the code path. The abstraction was also at the wrong layer: it should have been at a higher level, away from the filter itself, so it could (theoretically) be reused elsewhere, possibly in the future. The old code could theoretically be abused to be reusable, like in this PR, but the result is a bit messy and screams for wanting to abstract away the AIProvider stuff to a higher level.

This PR moves the abstraction to that higher level, promoting models (what we call "AI providers") to a first-class citizen in our code. This PR also splits the AI filter to have a shareable InstancedFilter for future model support with overly specific non-instanced filters.

Because of the new layering and new OpenAI library, we're also able to mock the OpenAI layer and test that our code handles responses in a reasonably safe way. Previously, we'd have to just try it out or wait for something to happen.

This refactoring also moves the filter.Media struct to media.Item because that's probably where it should have been at first. The event rendering code is also moved to a dedicated package for reusability. Both moves are to prevent import cycles (filter -> ai -> filter).

All of this means that when we go to add a second model, we'd:

1. Create a new provider in the ai package (with appropriate test)
2. Copy/paste filter_openai_omni to create a new non-instanced filter
3. Ensure the filter gets used in the community manager

... and that's it, hopefully. This then takes care of per-room enablement, vendor lock-in avoidance, etc for us. (Vendor lock-in is avoided by simply adding more and more models with minimal dependencies or copy/paste.)

Pull Request Checklist

• Pull request is based on the main branch.
• Pull request title describes the changes in a way a user would understand. For example, "Fix keywords filter not applying" instead of "Read keywords slice in a loop".
• Code style matches surrounding code.
• Tests are added for new code (and existing code) if possible.
  • If not possible, please explain why in your PR description.
• The CI checks pass.